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ABSTRACT 

Traditionally, spacecraft management has 
been performed by fixed teams of operators 
in Mission Operations Centers. The team 
cooperatively (1) ensures that payload(s) on 
spacecraft perform their work and (2) 
maintains die health and safety of the 
spacecraft through co mm anding and 
monitoring the spacecraft’s subsystems. In 
the future, the task demands will increase and 
overload the operators. This paper describes 
the traditional spacecraft management 
environment and describes a new concept in 
which groupware will be used to create a 
Virtual Mission Operations Center. 
Groupware tools will be used to better utilize 
available resources through increased 
automation and dynamic sharing of 
personnel among missions. 
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BACKGROUND 

NASA’s Goddard Space Flight Center 
(GSFC) is responsible for the ground control 
of near-earth scientific unmanned spacecraft. 
Each spacecraft (or series of spacecraft) has a 
unique mission. For example, EOS’s (the 
Earth Observing System) objective is to 
measure various earth resources, while 
COBE (the Cosmic Background Explorer) 
detects microwave radiation from deep . 
space. These spacecraft collect data for 
particular user communities. The users range 
from in-house NASA scientists to university 
researchers to commercial entities. 

The job of the ground control center is to 
ensure that the instruments (e.g., the 
payloads) on a spacecraft capture and 
transmit the data specified by the user 
communities. These centers are called 
payload operations control centers (POCCs). 
In addition, the POCC personnel are 
responsible for maintaining the health and 
safety of the spacecraft and its payload. The 
center’s relationships with the user 
communities and spacecraft are shown in 
Figure 1. Currently, each spacecraft has its 
own independent POCC, that is tailored and 
dedicated to supporting that mission. 

A POCC will only have contact with a 
spacecraft for a limited period of time, called 
a “pass.” This is because spacecraft can only 
transmit data when in contact with relay 
satellites or ground stations, both of which 
are shared resources. Typically a spacecraft 
sends telemetry data (electronically 
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transmitted data about the spacecraft) via 
either a relay satellite or special ground 
stations. The information is then passed to 
the POCC via a ground network. A typical 
pass may only last for 10 to 20 minutes, with 
a spacecraft making several passes during a 
24-hour time period. The activities that 
occur during a pass are called real-time 
activities. 

A control center is staffed by flight 
operations teams (FOTs) whose size is 
determined by the complexity of the 
spacecraft. Teams work in shifts so that all 
passes are supported. The FOT performs its 
command and control functions while in real- 
time contact with a spacecraft. Mission 
planning, scheduling, and bookkeeping 
activities occur in between passes. These 
activities are supported by subsystem 
specialists and engineers and are considered 
off-line activities. 

The real-time operations team generally 
consists of some combination of the 
following positions [5]: 

• Command controller -- responsible 
for configuring and monitoring the 
ground data network 

• Spacecraft analyst — performs 
analyses of spacecraft subsystem(s) to 
ensure health and safety 

• Flight supervisor — technical lead for 
team who performs or supervises 
both ground and spacecraft systems. 


The number of people assigned to each 
position varies with the mission. For 
example, for SAMPEX (the Solar 
Anomalous and Magnetospheric Particle 
Explorer) spacecraft, the FOT consists of 
three pairs of spacecraft analysts and 
command controllers who monitor the health 
and safety of the spacecraft and configure the 
ground station [9]. The personnel are cross- 
trained in each position. However, the 
analyst is a more senior position, and tends to 
act as a supervisor and error checker, while 
the command controller performs most of the 
command and control activities. For a larger 
mission, like the Hubble Space Telescope, 
the real-time team consists of 4 controllers, 
20 analysts, and 4 flight supervisors [5]. 

Each shift performs its work in the mission 
operations room (MOR). Traditionally, the 
room has been built specially for a spacecraft 
and dedicated to ensuring spacecraft's 
mission is accomplished. The MOR is 
staffed at all times, regardless of the 
activities being performed. A diagram of the 
primary work area of the SAMPEX MOR is 
shown in Figure 2. As shown in that figure, 
the two team members each monitor and 
perform work on two computers: a 
workstation (WS) and an X-terminal (XT), 
each with a 19” screen. Each team member 
also has a communications panel (Comm) for 
external communication (e.g., satellite 
ground station). A mission clock, located 
above the primary string, displays the current 
time and mission-specific time (i.e., time 
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Figure 2. Primary work area of SAMPEX MOR. 

until next pass). These devices make up the 
“primary string” where normal operations are 
conducted. Not shown in the figure are the 
backup string (used if there s a failure in the 
primary string), communications switch 
terminals, printers, processors, and storage 
areas. 

MISSION OPERATIONS 

The FOT’s command and control tasks (real- 
time activities) can be divided into three 
phases: pre-pass, in which the team verifies 
the center’s readiness to support the pass; 
pass, in which the team monitors the health 
of the spacecraft and controls operations 
(receiving, recording, and responding to 
telemetry data); and post-pass, in which the 
pass activities are reviewed, paperwork is 
filled out, and data are analyzed. 

This paper focuses on the FOT’s activities 
that occur during a pass. In particular it will 
focus on an important aspect of these 
operations called fault management. Fault 
management is the process of monitoring any 
faults or anomalies (irregular system 
behaviors) in a spacecraft’s subsystem or 
payload. This paper will first provide a more 
detailed description of a team’s fault 
management tasks, identify the problems 
with current practices, and discuss the 
cooperative work issues involved in fault 
management. The paper will then discuss a 


new operations concept that utilizes 
advanced automation and computer- 
supported cooperative work tools 
(groupware) and techniques to meet the 
challenges of future MOCs while adhering to 
the basic tenets of spacecraft control. 

Fault Management 

Fault management is a major task for the 
FOT that is not significantly automated and 
error prone. This section discusses the goals 
and activities involved in fault management 
and suggests some general causes for errors 
that occur. The goals of fault management 
are to (1) detect and compensate for 
anomalies, (2) identify the cause of 
anomalies when possible, (3) recover the 
faulty capabilities when possible, and (4) 
maintain safety and mission objectives based 
on the remaining functional capability when 
recovery is not possible [14]. 

When in real-time contact with the 
spacecraft, the operators actively monitor a 
large number of telemetry points in order to 
detect any faults. If faults go undetected, a 
spacecraft or one of its subsystems could be 
permanently damaged, resulting in lost data 
that are often irreplaceable or even the loss of 
the spacecraft. The monitoring of telemetry 
data is a very human-intensive process. 
Typically each operator monitors hundreds 
of parameters on multiple screens, looking 
for parameters that deviate from specified 
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levels or go outside of tolerances. In general, 
the spacecraft telemetry data are presented in 
alphanumeric format at a component level. 
These low-level data are grouped together on 
a display “page” at a subsystem level (e.g., 
all the data related to a battery). A typical 
display page from a SAMPEX display is 
show in Figure 3. 


Figure 3. Typical SAMPEX Analyst Screen. 

In many operations systems, very limited 
automated error-checking takes place only at 
the parameter level. The systems depend 
heavily on operators to detect and evaluate 
faults. Upon receipt of the data, the POCC’s 
computers will compare the massive streams 
of parameters to predefined look-up tables. 
The data are then displayed to the operators. 
When values are out of tolerance, they are 
highlighted by color coding. For example, 
valid parameters may be displayed in green, 
out-of-bounds in yellow, and critical faults in 
red. The human must detect these faults 
from the other normal data and determine the 
meaning and impact The human must 
integrate the individual alphanumeric values 
into a mental model of what is happening at 
the subsystem and system levels based on 
past performance knowledge, operational 
constraints, and operating procedures [5]. 

When sending commands to isolate and 
compensate for anomalies and to control the 
spacecraft, the operators must use a cryptic 
language called STOL. Little automation is 
available to assist operators. Because of the 
complexity of the language, the operators 


must sometimes reference a large manual 
(often unique for each mission) for command 
syntax. Paper documents must also be 
consulted to determine past performance, 
contingency plans, operational procedures, 
and spacecraft constraints and restrictions. 
Operators can easily become overloaded in 
this environment. This can be confirmed by 


that fact these activities account for the 
highest number of errors in spacecraft 
operations [5]. Such errors can be critical to 
the safety of the craft or affected subsystem. 

Cooperative Work in Fault 
Management 

The operators within a POCC and their 
support personnel work together as a team to 
achieve the common objective of 
maintaining the health and safety of a 
spacecraft in order to fulfill the needs of the 
spacecraft’s user community. Because of the 
complexity of spacecraft operations, teams of 
specially trained individuals (i.e., command 
controllers and analysts) must work together 
to accomplish the large amounts of work 
required for a pass. For many complex 
command and control operations, goals 
cannot be reached without cooperative work 
[1,2]. In such environments, die tasks are 
often too complex to be completed by 
individuals working in isolation and the 
cooperative work produces benefits that are 
greater than individual work. 
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In general, the FOT works semi- 
autonomously in the MOR, taking advantage 
of each member’s specialized knowledge. 
Interestingly though, Jones and Goyle [9] 
found that for the SAMPEX POCC, the 
command and fault management activities 
require the highest level of team cooperation. 
This makes sense considering that these tasks 
were found to be among the least automated 
and most error-prone. 

As Bendy, et al. [1] discovered in their 
ethnographic study of air traffic controllers in 
England, "What is important about the 
teamwork is not so much that the respective 
team members have individual tasks to 
perform, which they do, but that they are 
woven into a working division of labor.'" 

This can be seen in a description of how the 
SAMPEX FOT sends messages to its 
spacecraft [9]: 

1 . The spacecraft analyst reads the 
commands to the command controller. 

2. The command controller types in the 
commands. 

3. Both team members double-check the 
command syntax. 

4. The command controller sends the 
commands, while the analyst watches. 

5. Both members autonomously monitor 
to ensure the command is received 
properly. 

From this description, the cooperative nature 
of the work can be easily identified. In this 
example activity, die central focus of the 
cooperative work is on a shared physical 
device (i.e., the computer screen into which 
the command is typed). This type of 
cooperative work has been called co- 
presence and is found in other command and 
control settings [12]. 

Other aspects of fault management also 
involve semi-autonomous activities. During 
normal operations, the team members at 
SAMPEX each monitor separate data on 
their own display screens. However, the 
spacecraft analyst (acting as a supervisor) 
will look at the controller’s screens to 
observe those data. This is a manual way for 
the analyst to share the data that are primarily 
monitored by the controller. 


However, the level of coordination and 
cooperation increases when a fault is 
detected. The operators must work together 
to diagnose the fault and recover from it. 

This includes the sharing of data, formulating 
plans, and implementing those plans, all in 
real time. Primarily, the FOT works together 
for the purpose of verification, using 
redundancy as a safety measure [10]. Once a 
failure is detected, most activities related to 
failure management are performed 
cooperatively. When anomalies occur, it is 
often necessary to involve domain experts to 
resolve the anomalies. Thus, engineers, 
mission specialists, and other support 
personnel will, at various times, be brought 
into this process. Depending on the severity 
of the fault, engineers and other support 
personnel will join the operators inside the 
MOR to perform their work. During and in 
between passes, other teams of support staff 
may be working together remotely to solve a 
problem. Likewise, when there is a critical 
maneuver or when the mission is in a more 
intense or hazardous phase (e.g., launch), 
specialist often will relocate to the MOR to 
lend support during passes. 

This process becomes even more complex 
when an anomaly or fault cannot be resolved 
during a shift. In this situation, the staff that 
detected that fault must communicate the 
situation to the next FOT shift. This is 
typically done in two ways. The first method 
is through a bookkeeping process in which 
the fault in entered into anomaly reports, 
logbooks, and/or on a whiteboard located in 
the MOR. Critical information that needs to 
be passed to the next crew is written on this 
board. In this case, the information is passed 
asynchronously. The second method occurs 
synchronously. When the next crew arrives 
at the MOR, the relieved crew will discuss 
any information that they feel is important 
with the arriving crew. Thus, there is a 
significant amount of communication, 
coordination, and cooperation involved in 
fault management. 

Additional cooperative tasks are carried out 
during each pass. For example, the telemetry 
data from the spacecraft are usually first 
received by some intermediate source (i.e., a 
relay satellite) and then sent via various 
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network interfaces to the POCC’s MOR. To 
ensure that these communication channels 
are configured and operating properly, the 
FOT must remotely communicate (via a 
voice line) with personnel at these other 
support locations. 

These cooperative tasks can be effectively 
categorized using a time/space taxonomy 
(Table 1) [8]. That taxonomy divides 
cooperative work by location (whether the 
task interactions occur in the same or 
different places), and by time (whether the 
tasks are done at the same time, 
synchronously, or at different times, 
asynchronously). The above tasks are 
represented using this taxonomy in Table 1. 
Note that several of the activities occur in 
multiple cells of the matrix. 


Fourth, the environment is inflexible. To 
perform any work that requires 
communication, including monitoring, with a 
spacecraft, the personnel must be within the 
MOR. 

Unfortunately, the situation will only get 
worse. In the future, an increased number of 
smaller, yet more complex, spacecraft, will 
contain more sensors and subsystems that 
must be monitored [7]. If the current model 
is maintained, the already overloaded 
operators will easily become even more 
overwhelmed with all the additional data that 
must be monitored. With the current 
paradigm, the only solution to this problem 
would be to keep adding more operators and 
expanding the size of the control centers to 
support the additional people and equipment. 
However, there is movement towards 


Same Place 


Different Places 


Same Time Different Times 


Synchronous face-to-face 
interaction: 

• FOT fault management 

• Spacecraft commanding 

• Bookkeeping 

Asynchronous interaction: 

• Maintaining mission and 
fault status with logs and 
white board 

Synchronous distributed 
interaction: 

• Set-up and maintenance 
of network 

• Fault management when 
support personnel needed 

Asynchronous distributed 
interaction: 

• Distributed fault 
management 


Table 1. Time/Space Taxonomy of fault management and spacecraft control tasks 


Problems and Challenges 

This operations model has some significant 
drawbacks. First, each mission requires 
unique resources. Currently, each mission 
requires specially trained operators and 
dedicated facilities (i.e., physical room, 
computers, and communication equipment). 
Second, the FOT is at times overwhelmed by 
the sheer quantity of data that must be 
monitored in real-time during short-duration 
passes. Third, because the operators are 
performing the tedious task of monitoring 
these large quantities of data, they cannot 
perform more useful and intellectually 
stimulating work, such as trend analysis. 


building more autonomous spacecraft, using 
on-board processors, that will operate in 
more of a peer-to-peer relationship [7]. 
However, this too will require new, but 
different, demands on the human ground- 
based operators. 

Not only will spacecraft become more 
complex, the length of missions will be 
extended to 10 to 15 years [5]. Significant 
crew turnover will doubtless occur during 
such a long period. Provisions must be made 
to train new team members and maintain 
mission knowledge. Also, computer 
technology (both hardware and software) 
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will make tremendous advances over that 
time period. Unless there is a flexible way to 
introduce and upgrade the MOR equipment, 
systems will become outdated and 
unsupported, making maintenance a burden. 

Because of budgetary constraints and 
increased automation, NASA plans to move 
away from the physically and functionally 
disparate control center concept to a unified 
mission operations center (MOC) concept in 
which all aspects of a mission will be located 
in one place. In this concept, fewer people 
will have to work together under tighter 
budget constraints. To further reduce 
operations costs, FOTs may be tasked to 
support multiple missions. 

Also, operators are having to interact with 
more external groups. The MOC concept 
calls for the number of science users to be 
increasing. For example, scientists will be 
given more control access to experiments 
being conducted in space. Instead of 
scientists making requests for data that are 
then handed off to the FOT, the scientists 
remotely will be able to manipulate these 
experiments. These investigators will be 
distributed all over the world, using a wide 
variety of equipment. 

DESIGNING FOR THE FUTURE 

The MOC of the future will rely on many 
forms of advanced automation. However, 
any design for a MOC must adhere to three 
basic tenets of spacecraft control [16]: (1) 
humans must have the ability to control all 
reasonable processes and decisions, (2) 
humans must have access to all the available 
data, and (3) the system must be able to 
support the inclusion of personnel (e.g., 
specialists) as needed. Based upon these 
requirements and the new mission challenges 
described in the previous section, the design 
goals for future MOCs are listed below: 

• Seamless - allowing operators to easily 
access and display any level of mission data, 
from low-level component data to graphical 
representations of system-level states [15]. 


• Extensible - allowing the number of 
operations personnel and computational 
resources to increase and decrease as needed. 

• Adaptable — providing the appropriate 
levels of expertise and layout based on 
operator preferences, mental models, and 
needs [13]. 

• Integrated — combining the numerous new 
tools with existing capabilities, legacy 
applications, and system software into a 
common tool set with a consistent user 
interface design, in order to help facilitate 
user acceptance [11, 17]. 

• Empowering — providing the FOT with the 
necessary applications and resources to 
perform useful tasks that help advance the 
mission work (i.e., putting the tools in the 
hands of the people who do the work) [6, 

18]. 

• Dynamically Heterarchical — supporting 
dynamic allocation of responsibilities, such 
that at any point in a mission, humans can 
take control of routinely automated tasks, 
assign tasks to be automatically controlled 
by the system, or reassign control and 
responsibility for tasks among the FOT. 

The Virtual Mission Operations Center 

At GSFC, these requirements are forming the 
basis for a new operations concept called the 
Virtual Mission Operations Center or 
VMOC. In the VMOC, spacecraft 
management would be conducted by 
dynamically configured teams who act as on- 
demand supervisors. The supervisory tasks 
would take advantage of increased 
automation that would allow for the 
implementation of the proactive 
management-by-exception paradigm [16]. 
This concept will be extended to distributed 
teams, where personnel are brought on to 
support missions from their remote locations 
using their own computers and equipment, 
without traveling to the physical MOC. A 
graphic representing the virtual operations 
concept is presented in Figure 4. 

Thus, the center would be virtual in that its 
personnel and functions are dynamically 


7 



\ 



\ 


II 



\ ..<# Other facilities 


Teams of engineers 
and scientist 





\ 


\ 


/ 


, \1 -/ 

, v pf^gical \ 




Specialists & equipment 

in their offices j 

/ 


/ 


/ 


\ / 

>v 


Universities & 
other researchers 


Decision makers 

Same Center 
Remote Locations 


( 



Commercial 

firms 


Figure 4: Virtual Operations Concept 

distributed both spatially and temporally, 
allowing VMOC personnel to work together 
as members of the same team, whether they 
are working at the same time in the same 
room or distributed across the country with 
people participating at different times. In 
other words, the VMOC would exist as a 
dynamic, distributed collection of people and 
resources that can operate at any time in any 
place. Implementing this paradigm would 
also reduce costs because it would alleviate 
the need to have teams of operators watching 
data in around-the-clock shifts. For example, 
in the VMOC one or two team members 
could staff the MOR during daytime hours 
and could access specialists on an as-needed 
basis; or, during unmanned evening hours, 
team members could be automatically 
located and “paged” should there be a fault. 


Potentially, VMOCs could even support 
multiple missions by using virtual teams [6]. 
In these virtual teams, people may 
simultaneously be members of more than one 
team by splitting their time among the 
missions and working together for only as 
long as it takes to complete a task. This 
method better utilizes the team members 
during large gaps between spacecraft passes. 

CSCW in the VMOC 

Because of the degree of collaborative effort 
involved in supporting spacecraft operations 
in the VMOC, computer-supported 
cooperative work (CSCW) tools and 
techniques will need to be incorporated and 
integrated into the infrastructure of the new 
design. Unfortunately, until now, the 
development of new computer tools has 
primarily focused on supporting individual 
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members of the team. This is similar to the 
automation approach in the air traffic control 
systems [1]. Instead of relying on this old 
approach to automation, the new paradigm 
will focus on tools that support the group as 
a whole, as well as individuals, because the 
cooperative aspects of FOT activities are 
now recognized as critical to success and 
must be properly supported. 

Moreover, the standard approach of 
implementing new technologies alone will 
not be able to solve all the challenges (e.g., 
supporting multiple missions, reducing the 
size of the teams, providing training) that 
will face future FOTs. New management 
paradigms and work processes will also need 
to be developed. Groupware will allow for 
the introduction of these new processes. The 
groupware will need to support both 
synchronous and asynchronous activities that 
occur physically inside the MOR and 
distributed remotely throughout the world. 
The groupware tools will need to support 
each of the following aspects of group work 
[3]: communication — the ability to transmit 
information electronically, cooperation — 
sharing of information to reach a common 
goal, and coordination — support and 
management of group work tools. The 
ultimate goal of using groupware will be to 
provide the support needed to increase 
organizational flexibility and information 
flow. Some of the many potential uses of 
groupware are presented below. 

• Intelligent TeamBuilder — This application 
would be used by the FOT to locate 
appropriate personnel to support real-time 
mission needs. Using this tool, a member of 
the core FOT would be able to check the 
availability of a support specialist and the 
best means of contacting the person. For 
example, if a spacecraft’s thermal subsystem 
should fail, the VMOC’s systems analyst 
could use die TeamBuilder to get a listing of 
available personnel who could be brought 
on-line to address that anomaly. The 
TeamBuilder could display a list of all the 
available staff with thermal subsystem 
expertise, along with those people’s 
resources (e.g., computer equipment and 
communications equipment), location (e.g., 
building, facility, home) and the means of 


contacting the people (e.g., fax, email, or 
phone). The availability of staff could be 
based on an agency-wide on-line scheduler 
that can be automatically accessed by the 
TeamBuilder. 

• Multi-User Hypertexts — Hypertexts would 
be created to allow team members to access 
mission-specific information and command 
syntax on-line so that the FOT members 
would not need to leave their workstations 
during a pass. The hypertexts would be 
multi-user so that core team members, as 
well as local and remote support personnel, 
could work cooperatively. For example, if a 
fault was related to a gyroscope, a systems 
analyst and gyroscope specialist (perhaps 
located at another center) could 
simultaneously view the documentation 
related to that subsystem and work together 
to diagnose the fault. That documentation 
could contain procedural text, schematic 
diagrams, and personal notes (user 
annotations) about experiences with various 
components. 

• Multi-media Screen Sharing and Email — 
A multi-media screen sharing tool would be 
a critical element in the YMOC. A tool is 
envisioned that will allow any member of the 
FOT to bring up an image or window that is 
displayed on any other member’s screen. 

This will be true locally within the physical 
MOR as well as remotely for sharing 
information among distributed members of 
the support team. The screen sharing 
capability will be integrated with an email 
system that allows the group to actively 
comment on the shared image. This is 
similar to the Active Mail concept [4] in 
which a group of people can have an 
integrated interactive electronic conversation 
about a shared document. For example, this 
tool could be used in a situation in which an 
operator detects some anomalous 
information on her screen. She may not 
know the meaning or consequences of that 
data, so she contacts a specialist for advice 
(perhaps via the TeamBuilder tool). She 
sends the specialist a copy of her screen 
along with a message describing the 
problem. This avoids the problems involved 
with the specialist having to travel to the 
MOC to view the data or trying to 
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understand the operator’s oral descriptions of 
what’s on the screen. The specialist could 
then look at the data or graphic and send a 
message back to the operator with advice. If 
it is a particularly complex problem, 
additional specialists could be brought into 
the conversation and sent copies of the 
screen in order to solve the problem 
cooperatively. 

• Intelligent Form Filler and Router — 
Typically, a FOT spends a significant 
amount of time performing bookkeeping 
tasks. For the most part, die FOT manually 
fill out various reports and forms including 
logbooks, anomaly reports, pass plans, and 
clock checks. Where possible, the intelligent 
form filler and router would automatically 
fill data into the appropriate forms based on 
data already in the systems or triggered by 
pre-defined events (e.g., a computer-detected 
anomaly). The software would also improve 
the efficiency of the workflow by 
automatically routing the forms and reports 
to the appropriate people. Should this 
mechanism prove effective, it could be 
expanded to include the automating of other 
processes, such as the automatic routing of 
data to the appropriate user communities. 

• Integrated Computer-Based Training 
( CBT) - In current MOCs, most of the 
training is on-the-job, with the trainee 
looking over the trainer’s shoulder. Because 
of the advanced screen sharing and 
distributed control features built into the 
VMOC, a training capability could be built 
on top of those capabilities. For example, a 
new trainee could remotely monitor a live 
support mission via screen sharing without 
having to interfere with and distract the 
active operators. The training could begin 
with simulations of a support and then move 
to actually supporting a mission. As the 
trainee gains knowledge of the system, an 
analyst (the trainer) could assign and 
delegate increasingly more complex tasks to 
the trainee. At the same time, the trainer 
could monitor the trainee’s work in real- 
time, offering recommendations and advice. 
In addition, other CBT features, such as 
individualized instruction, team-based 
training, and tutorials could be implemented 
to improve the training processes. 


• Team-Based Agents — One of the more 
critical new tools would be the use of on-line 
agents that could be taught to perform the 
parameter-level data monitoring activities. 
The goal of implementing agents is to shift 
the humans into more of a supervisory role 
instead of being full-time “data slaves.” The 
agents would be incorporated as team 
members [14], monitoring the data and 
alerting the human team members of 
potential problems before they become 
faults. It should be noted that the agents 
would not be the critical decision-makers. 
Instead, the agents would be used to support 
and enhance the operators’ expertise by 
automating routine duties and by translating 
the enormous amount of low-level data into 
higher-level information that is more readily 
usable by the operators. Such software has 
been classified as “cognitive tools” [19]. 

This preserves the basic tenet that humans 
can control all tasks while freeing the 
humans to perform more interesting and 
sophisticated fault management activities, 
such as trend analysis. If implemented 
properly, such a machine-supported role 
could detect anomalies before they become 
larger mission-critical problems; thus, 
allowing the team to work in a more 
proactive instead of reactive manner. This is 
known as the management-by-exception 
paradigm (for more details see [16]). 

Advantages of the VMOC 

The VMOC adheres to the tenets of 
spacecraft control; humans will control all 
reasonable processes and decision and have 
access to all available data, and the system 
will support additional persons as needed. In 
addition, the VMOC is seamless, integrated, 
and adaptable; the FOT will be able to access 
and display any level of information from a 
common tool set with a consistent user 
interface, based on operator preferences, 
mental models, and needs. The VMOC will 
empower the FOT to perform useful mission 
tasks, assign tasks to be automatically 
controlled, and take or reassign control as 
necessary. 

Moving towards a VMOC environment has 
many advantages over the present MOCs. 
Most of the advantages stem from new 
organizational flexibility and increased 
information flow. With the proper tools, 
people will be able to work where they are 
normally located and have immediate access 
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and getting experts involved on a shorter 
notice because they will not need to travel to 
the MOCs. Also, people will be able to 
respond better. When people are located in 
their own facilities or offices, they will have 
access to all of their own resources (i.e., 
hardware, software, manuals). This is also 
an opportunity to save costs because there 
will be less need for travel and to have 
additional dedicated equipment located in 
central places. 

CONCLUSION 

Currently, flight operations teams (FOTs) are 
working collaboratively around the clock to 
ensure that the spacecraft payloads capture 
and transmit the data specified by their user 
communities. During passes, the FOTs must 
monitor low-level telemetry data and send 
commands in a cognitively overwhelming 
environment. This situation will continue to 
worsen as spacecraft become more complex, 
mission lives are extended, external 
investigators gain more access to their 
experiments, and budgetary constraints 
reduce the size of the teams. 

Designing the future generations of mission 
operation centers (MOCs) will require a 
thorough understanding of the group 
processes that are occurring in the current 
centers so that automation can be properly 
implemented. Automation must support the 
cooperative aspects of spacecraft operations. 
A new design concept called the Virtual 
Mission Operations Center (VMOC) is being 
designed to meet these new challenges. A 
critical aspect of the VMOC will be its 
implementation of groupware, along with the 
organization infrastructure to support it, to 
support and enhance the team aspects of 
mission operations. However, over the next 
5 to 10 years, many technical, social, and 
organizational challenges must be overcome 
for the VMOC to be successful and to meet 
the needs of future generations of spacecraft 
users. 


REFERENCES 

1. Bently, R., Hughs, J. A., Randall, D., 
Rodden, T., Sawyer, P., Shapiro, D., & 
Sommerville, I. (1992). Ethnograph- 
ically-Informed Systems Design for Air 
Traffic Control. In CSCW'92: ACM 
1992 Conference on Computer- 
Supported Cooperative Work, (pp. 123- 
129). Toronto: ACM. 

2. Bushman, J. B., & Mitchell, C. M. 
(1993). ALLY: An Operator’s Associate 
for Cooperative Supervisory Control 
Systems. IEEE Transactions on Systems, 
Man, and Cybernetics, 23(1), 111-128. 

3. Ellis, C. A., Gibbs, S. J., & Rein, G. L. 
(1992). Groupware: Some Issues and 
Experiences. In R. M. Baecker (Eds.), 
Readings in Groupware and Computer- 
Supported Cooperative Work (pp. 9-28). 
San Mateo, CA: Morgan Kaufmann 
Publishers, Inc. 

4. Goldberg, Y., Safran, M., & Shapiro, E. 
(1992). Active Mail -- A framework for 
Implementing Groupware. In CSCW '92: 
ACM 1992 Conference on Computer - 
Supported Cooperative Work, (pp. 75- 
83). Toronto: ACM. 

5. Hall, G. A., Jaworski, A., Schuetzle, J., 
Thompson, J. T., & Zoch, D. (1991). A 
Control Center Analysis: Current 
Functions, Future Needs, and Beneficial 
Directions (Contract NAS-5-31478). 
Loral AeroSys. 

6. Hammer, M., & Champy, J. (1993). 
Reengineering The Corporation: A 
Manifesto for Business Revolution. New 
York: HarperBusiness. 

7. Jaworski, A., Hall, G. A., & Zoch, D. 
(1992). An Architecture for Future 
Mission Operations Control Centers 
(Contract NAS-5-31478). Loral 
AeroSys. 

8. Johansen, R., Sibbet, D., Benson, S., 
Martin, A., Mittman, R., & Saffo, P. 
(1991). Leading Business Teams. 


11 


Reading, MA: Addison-Wesley 
Publishing Company. 

9. Jones, P. M., & Goyle, V. (1993). A 
Field Study ofTPOCC Mission 
Operations: Knowledge Requirements 
and Cooperative Work (Report No. 
EPRL-93-05). Engineering Psychology 
Research Laboratory, University of 
Illinois. 

10. Jones, P. M., Patterson, E. S., & Goyle, 
V. (1993). Modeling and Intelligent 
Aiding for Cooperative Work in Mission 
Operations. In Proceedings of the 1993 
IEEE International Conference on 
Systems Man and Cybernetics , 3 (pp. 38- 
43). 

11. Lantz, K. A. (1988). An Experiment in 
Integrated Multimedia Conferencing. In 
I. Grief (Ed.), Computer-Supported 
Cooperative Work: A Book of Readings 
(pp. 783). San Mateo, CA: Morgan 
Kaufmann Publishers, Inc. 

12. Luff, P., Heath, C., & Greatbateh, D. 
(1992). Tasks-in-Interaction: Paper and 
Screen Based Documentation in 
Collaborative Activity. In CSCW '92: 
ACM 1992 Conference on Computer - 
Supported Cooperative Work, (pp. 163- 
170). Toronto: ACM. 

13. Mackay, W. E. (1990). Patterns of 
Sharing Customizable Software. In 
CSCW'90: Proceedings of the 
Conference on Computer-Supported 
Cooperative Work, (pp. 209-221). Los 
Angeles, CA: ACM. 

14. Malin, J. T., & Schreckenghost, D. L. 
(1992). Making Intelligent Systems Team 
Players: Overview for Designe rs 
(NASA Technical Memorandum No. 
104751). National Aeronautics and 
Space Administration, Lyndon B. 
Johnson Space Center. 

15. McGraw, K. L. (1993). Designing and 
Evaluating User Interfaces for 
Knowledge-Based Systems. New York: 
Ellis Horwood. 


16. Moore, M., & Fox, J. (1993). The 
Virtual Mission Operations Center. In 
SOAR '93. Houston, TX: NASA. 

17. Satzinger, J., & Olfman, L. (1992). A 
Research Program to Assess User 
Perceptions of Group Work Support. In 
Human Factors in Computing Systems: 
SIGCHI '92, (pp. 99-106). Monterey, 
CA: ACM. 

18. Tapscott, D., & Caston, A. (1993). 
Paradigm Shift. New York: McGraw- 
Hill, Inc. 

19. Woods, D. D., Johannesen, L., & Potter, 
S. S. (1991). Human Interaction with 
Intelligent Systems: An Overview and 
Bibliography. SIGART Bulletin, 2(5), 39- 
50. 


12 


